1. Technical Field
The present invention relates to data processing systems and, in particular, to batch processing in a distributed object environment. Still more particularly, the present invention provides a component model for batch computing in a distributed object environment.
2. Description of Related Art
Distributed object component technology has evolved to provide a solid foundation for modern business application design in online transaction processing systems. These component technologies include, for example, the use of the JAVA programming language, the JAVA 2 Enterprise Edition (J2EE) programming model, and component technologies, such as Java Server Pages (JSPs), Servlets, and Portlets for online presentation logic. Component technologies also includes, for example, the use of Enterprise JAVA Bean (EJB) SessionBeans and EntityBeans for transactional business logic and data management.
These component models are expressly designed to enable a strong separation of concerns between business application logic and the underlying information systems technology on which those application components are hosted. This separation enables application developers to focus on domain knowledge, adding value to their business, and to avoid the intricacies of distributed information systems technology. The EJB component models are designed to support transactional processing of business functions, leveraging the ACID (Atomicity, Consistency, Isolation, and Durability) properties of distributed two-phase commit protocols to ensure a very high degree of information integrity. Further, these component models enable declarative approaches to enforcing security, the relationships between objects, internationalization, serviceability, and persistence, essentially virtualizing the relationship of the business application component to its underlying information system.
The primary limitation of object component technologies, such as those defined by J2EE, is that they are designed for online transaction processing. Business transactions are typically initiated by an end user in real time, requesting that a function be performed by the business application, usually resulting in an update to business data that gets transactionally committed before returning a result to the user. Component models and container management are designed to operate on one request at a time. Any multi-processing is achieved through multi-threading and workload clustering, but in a way that retains the illusion of sequential processing. Transaction, security, and persistence processing are structured around the idea that each request is initiated distinctly for a unique user and for a unique end purpose.
However, there is a large demand for bulk (batch) processing. Besides being a traditional approach to data processing—in fact, the incumbent of modern electronic computing—bulk processing also represents a significant portion of how enterprises continue to conduct their business. Bank checks are processed in bulk in clearing centers every night. Interest on savings and loan accounts is computed in bulk every week. Billing statements are printed in bulk every month. Corporate payments are collected up and posted every week. Paychecks are cut and distributed every couple of weeks. Customers often want to be able to execute these transactions in batch programs, processing many hundreds, thousands, or even millions of transactions in a single job. Moreover, many customers want to be able to re-use the exact same business logic and programming artifacts in both their online transaction processing and in their batch programs. For example, an account withdrawal function should do the same thing whether it is being performed for a bank customer standing at an automatic teller machine or for a check that was posted through a clearing house in the middle of the night.
Batch computing has been a long-time staple of mainframe computing in languages, such as COBOL and PL/I, and as standalone programs or combined in subsystems, such as CICS and IMS. However, batch computing has never been combined with distributed object component technologies. Therefore, one must perform batch processing by stringing together a large number of single transactions, which is inefficient, or by performing one large transaction, which will likely affect online processing.